To improve the reliability of Internet access, customers and data centers often connect to an Internet Service Provider (ISP) using multiple access links. However, customers find that inbound traffic usage of their access links is heavily unbalanced and underutilizes the available access link capacity.
To aid customers in addressing this problem, a solution that allows an ISP to flexibly engineer interdomain routing on a per-customer, per-router basis, taking input from both network-wide and customer-specific policies was created as the Intelligent Route Service Control Point (IRSCP) architecture. The IRSCP implements precise and manageable control of interdomain routing, presenting an interface that enables a large range of Traffic Engineering (TE) applications of which customer traffic load balancing is only one example. IRSCP is a centralized network control device that interacts with Provider Edge (PE) routers to conduct route selection, gateway selection, load balance, schedule maintenance and policy modification.
The IRSCP architecture allows a network operator to flexibly control routing between the traffic ingresses and egresses within an ISP's network without modifying the ISP's existing routers. The IRSCP subsumes the control plane of an ISP's network by replacing the distributed Border Gateway Protocol (BGP) decision process of each router in the network with a flexible, logically centralized application controlled route computation. The IRSCP supplements the traditional BGP decision process with an explicitly ranked decision process that allows route control applications to provide a per-destination, per-router explicit ranking of traffic egresses.
BGP is the core routing protocol of the Internet. It maintains a table of IP networks or prefixes which designate network reachability among Autonomous Systems (ASs) and is a path vector protocol. BGP does not use traditional Interior Gateway Protocol (IGP) metrics, but makes routing decisions based on path, network policies and/or rule sets.
Internet routing deals with finding a loop free path between source and destination endpoints. Within a particular network or AS, routing is realized by a fixed, simple BGP decision process that ensures consistent decision making between the routers in the network while respecting the network operator's policies.
The IRSCP subsumes the routing decision process in a system framework separate from the routers in a network towards a new routing infrastructure. IRSCP eases the realization of applications that dynamically manage connectivity. Specifically, an ISP's route control application is allowed to control route selection through an independent interface. The interface is based on the abstraction of a ranking of egress routes for each router and destination. Application means network control and management functions that a service provider would employ to provide services.
The IRSCP maintains complete control of the route selection function for all routers in the network. This is achieved by having the IRSCP communicate directly with routers in neighboring networks via exterior BGP (eBGP), in addition to communicating interior BGP (iBGP) with the routers in the IRSCP enabled network. This gives IRSCP full visibility of all routes available in the network. The IRSCP is the sole controller of BGP route selection, meaning that all of the network's routing policy can be handled by the route control application through the IRSCP, as opposed to placing policy configuration on the routers themselves.
Realizing an IRSCP that has complete control of route selection faces two important challenges. First, because routers in the IRSCP-enabled network completely rely on the IRSCP for routing decisions, the IRSCP infrastructure must be substantially more robust than an iBGP IRSCP. A complete failure of an eBGP IRSCP would cause all routes in the network to be withdrawn incapacitating the underlying network.
Second, the need for complete route control and full visibility poses significant scalability challenges. To address these concerns, the IRSCP functionality is partitioned and distributed across a number of servers to ensure consistent decision making as a whole. Although the IRSCP is physically distributed, it presents a logically centralized abstraction from the point of view of a route control application. While the route control application has to interact with all IRSCP servers, it can remain agnostic to where these servers reside in the network and what set of routers each server controls.
The IRSCP employs a modified BGP decision process, an explicitly ranked decision process, in conjunction with a route control interface that enables route control applications to directly guide the route selection process.
FIG. 1A shows a simplified view of the physical infrastructure of a Multiprotocol Label Switching (MPLS) enabled ISP network with solid lines representing physical links. Routers at the periphery of the ISP network couple to other ISPs (peers) and to customers. These routers are Provider Edge (PE) routers. Routers that interconnect the PE routers are Provider (P) routers. Routers that couple to the PE routers are Customer Edge (CE) routers. A CE router is also used to represent peer routers that connect to the ISP. BGP allows an ISP to learn about destinations reachable through its customers and peers. Typically every PE router maintains BGP sessions with its attached CE routers and also with other PE routers in the ISP network. The CE router sessions are eBGP sessions and the PE router sessions are iBGP sessions.
FIG. 1B shows representative communications with MPLS tunnels and iBGP represented by bold broken lines and eBGP represented by broken lines. When a PE router receives a route through its eBGP session, it propagates the route to other PE routers through iBGP sessions, allowing every PE router to learn how to reach every peer or customer network. The path traffic follows between ingress and egress routers is determined by Interior Gateway Protocol (IGP), such as Open Shortest Path First (OSPF). In an MPLS network, label switched paths are established between all PE routers obviating the need to run BGP on P routers. While MPLS is used for setting up and managing tunnels, the actual tunnel path over which a tunnel is set up is determined by the IGP.
A PE router usually receives more than one egress route for a given destination and must run a route selection algorithm called the BGP decision process to select the best route to use for data forwarding.
FIG. 1C shows a specific problem introduced by BGP's hot-potato routing, motivating the need to enhance route selection with an IRSCP. The customer in FIG. 1C has multi-homed to the provider network for the purpose of redundancy and the same destinations are reachable via both links shown by solid arrows. All PE routers in the provider network have two possible routes to reach the customer network. Most of the traffic destined to the customer network enters the provider network from the peering ISP network. Assuming unit TOP costs for each internal provider link in FIG. 1A, the two ingress PE routers prefer the route via the top egress PE router coupled to the customer network (FIG. 1C). This leads to a load imbalance on the two egress links, with the top egress link carrying all or most of the traffic, which in turn may result in congestion.
In practice the customer or ISP may prefer the ISP to load balance traffic on the two egress links while still considering the path cost between ingress and egress. In the IRSCP this is achieved by basing the decision process on the input from a load balancing route control application run by the ISP, which takes into account IGP path cost, as well as “offered” ingress load and capacity of egress links. The route control application directly controls route selection for each PE router and, in this example, directs the two ingress PE routers to each send traffic to a different egress PE router. This routing solution cannot be achieved in BGP without manipulating BGP attributes on multiple PE routers through vendor specific configuration languages.
Since customers can manipulate the live routing process in VPN networks via an IRSCP Service Manager (SM), it would make IP network troubleshooting more time consuming and labor intensive. Technicians would not only need to analyze route group settings, but would also need to examine IRSCP configurations.
When an IRSCP outage occurs, technicians have to locate the problem from serving site PE routers to member site PE routers by manually querying various inventory systems. Serving site PE routers are predefined according to a hub-spoke implementation. A hub or a serving site PE router can communicate to any PE routers in a network while a spoke or a member site PE router can not communicate to another member site PE router directly. A member site PE router must communicate with a designated serving site PE router first. Since a serving site PE router is the destination of a member site PE router, troubleshooting has to start from a serving site PE router and then to its member site PE routers.
Most telecommunications companies rely on technicians or semi-automated troubleshooting tools to identify and locate network problems including IRSCP. What is desired are systems and methods that perform automated non-intrusive testing to locate IRSCP problems without disrupting customer service.